What & why

On the Sales Order, Sales Quote, Blanket Sales Order, and Sales Invoice pages, "Bill-to Name 2" is only editable when the Bill-to option is "Another Customer". Every other field in the bill-to address group (Address, Address 2, City, County, Post Code, Country/Region Code, Contact No., Contact) is editable when "Custom Address" is selected or when the bill-to customer differs from the sell-to customer. As noted in the issue triage, the field was simply missed when that editability logic was applied to the group.

This change gives "Bill-to Name 2" the same Editable and Enabled expression as the rest of the group on those four pages. The country layers that carry copies of these pages (APAC, BE, CH, ES, FR, GB, IT, NA, NL, NO, RU) receive the identical two-property change, following the established practice of propagating W1 fixes to the localization layers.

Linked work

Fixes #8312

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome

• Extended the four existing bill-to editability tests (CustomAddressBillToOptionOnSalesQuotePage, ...SalesOrderPage, ...SalesInvoicePage, ...SalesBlanketOrderPage in UTPageActionsControls.Codeunit.al) so they now also assert that "Bill-to Name 2" is editable when "Custom Address" is selected, alongside the sibling address fields they already cover.
• Verified that every page copy across the localization layers received the identical two-line change and nothing else (the diff is uniform, and byte order marks and line endings of the touched files are preserved).
• Confirmed on the Sales Header table that "Bill-to Name 2" (field 6) is a plain text field with no OnValidate logic and no table relation, so widening its page editability has no side effects beyond allowing input.
• I did not build the Base Application locally; the change is limited to two page control properties per page, replicating the exact expression already used by all sibling fields, and relies on the extended test coverage in CI.

Risk & compatibility

• The Sales Credit Memo and Sales Return Order pages are intentionally not touched: they have no BillToOptions control, which the triage comment on the issue asks to track as a separate item.
• The purchase documents have the same inconsistency on "Pay-to Name 2" (Purchase Quote, Purchase Order, Purchase Invoice). That is deliberately out of scope here and will be reported as its own issue.
• No breaking changes: no object signatures, events, or table schema are affected.